since we're enforcing a 1:1 mapping of authority to pda, this field is superfluous since it must be passed in the tx, right?

API update here: #1 (comment)

Think parallelism is a legitimate usecase requested from foundation.

p sure it's the nonce hash that prevents "parallelism", not the authority

we need to tell these people that we're shipping an mvp replacement here, not taking feature requests

An authority makes sense if we want to cover the existing use-case, where you have a nonce authority that must sign to advance the nonce, and then a bunch of other signers who are signers on the transaction.

A single authority can manage multiple nonce accounts for different offline signers. As a custodian, I might use the same authority for many different clients. When they want to move funds, they sign with one of my many accounts

sure but we already have the authorities and the submit ix accounts list, as presently defined, only supports a single vault account. we can encode its authority in the ordering, like we do with the fee payer on outer tx, then assert it by virtue of the associated pda being passed. this could be trivially extended to multiple vault accounts should we choose with a vault count in the ix data

So I'm sure we're on the same page, there's two kinds of accounts: the PDA being promoted, and the account storing the hash and authority. For clarity, let's call the PDA the "vault" since it actually owns assets, and the other account the "durable signer".

In that sense, transactions must have at least one durable signer, and need to support having multiple vaults. Otherwise this program won't support existing use-cases, where multiple keypairs perform offline signing.

the pubkey, address, account conflation in this ecosystem continues to pay out...

the account itself isn't really relevant to my point. sure it's stored at the authority's pda, but that pda is also the effective signer for inner payload execution. i don't see how it matters how many auxiliary programmatic signers we have on the inner payload, we only care about knowing which accounts index is the vault's to match the nonce stored there to what's signed on the inner payload. i'm proposing that we encode that information in the accounts list and forego duplicating the authority in the vault. so we'd have accounts indexes like this...

1. vault address
2. slothashes sysvar
3. instructions sysvar
4. vault authority pubkey
5. aux signer 1 pubkey
...
5+N. aux signer N pubkey
5+N+1. aux signer 1 pda
...
5+N+N. aux signer N pda
5+N+N+1. inner instruction account 1
...

at the cost of a (one byte?) aux signer count in the instruction payload

then the logic looks something like

// check sigs
vault = accounts[1]
vault_auth = accounts[4]
if (pda(vault_auth.address) == vault.address) {
  vault_data = VaultData::try_from(vault.data)?;
  if submit_ix_data.nonce == vault_data.nonce {
    // match aux signer[i] pda(accounts[5+i].address):accounts[5+N+i].address mappings
    // do the cpis
    ...
  }
}

i'm failing to see what storing the authority pubkey gains us

Given this thread changes the names of the entities in this PR, it's an indication they probably need another pass (though "vault" is a specific defi primitive that could be a naming collision).

sure it's stored at the authority's pda
...
if (pda(vault_auth.address) == vault.address) {

I think there’s a model mismatch here. The account storing the nonce hash is not stored at the authority’s PDA.

This PR has two entities:

• DurableSignerPda: the authority derived from cold-wallet keypair (the programmatic signer)
• DurableSignerAccount: entity storing the nonce hash w/ an authority. An authority can own many and live at arbitrary addresses.

Without an authority listed in that account (and checked in program), anyone could increment that nonce and invalidate offline signed inner tx.

The reason where there is not a single DurableSignerAccount at a PDA of the authority is to support the cold-signer batch usecase where someone wants to cold-sign many at once (with multiple accounts -- so multiple nonce hashes).

i'm thinking maybe we should just drop the "nonce" terminology altogether. any "programmatic signer/authority" can be used to decouple asset authority from signatures that must cover the recent blockhash

Interesting. Would spl-program-signer or spl-pda-authority or spl-authority-proxy be more accurate?

spl-ed25519-signer?

@joncinque join the bikeshed session!

I've been summoned! I really like including ed25519. On the other hand, this is still meant to cover single-use durable signatures, so how about spl-ed25519-durable-signer?

Updated terms!

there really isn't anything "durable" about this thing tho. that qualifier was added to the original feature as a call out to its extending the ttl of an otherwise short-lived nonce value. here we're simply never signing a nonce with a lifetime at all. this is so much more powerful and shouldn't be burdened by historical artifacts. the technology has advanced to the point as to make the old ways irrelevant. let them die

wherever we land, we should also rename the repo before it gets much content

I'm not sure I understand -- "durable" means "long-lasting", and this program provides a long-lasting way to sign transactions. What are other powers that you want to highlight with the name?

Someone could make a different version of this program that requires signing the same blockhash as the outer transaction, which could be called ed25519-blockhash-signer. In this case, would ed25519-hash-signer be better? Or if you feel really strongly about spl-ed25519-signer, I can get behind it

An authority makes sense if we want to cover the existing use-case, where you have a nonce authority that must sign to advance the nonce, and then a bunch of other signers who are signers on the transaction.

A single authority can manage multiple nonce accounts for different offline signers. As a custodian, I might use the same authority for many different clients. When they want to move funds, they sign with one of my many accounts

This is clever! And makes sense, it's a great show of how this would work

Yeah, I found myself thinking through auth for this message and found the duplication annoying. Think this method addresses that!

I wasn't sure about this restriction, but we can always relax it in the future if there are legitimate use-cases hampered by it

i think the only real concern is that it makes v1 transactions a prerequisite for consumers that require compute budget instructions

The program could potentially just skip compute budget instructions, no?

sure. more shit to maintain in the program tho. more blast radius for upstream bugs. more shit to consider during deprecation. we're patching oob panic in v1 tx parsing rn. the more the program knows, the worse off it is

The trade off is
A - Hot wallet cannot insert ixs before/after inner tx and can only pass compute budget / priority fee params via the v1 transaction format.
vs
B - Hot wallet can insert ixs before or after. Inner tx doesn't have guarantees of what's run in the tx along with its CPIs.

It feels like B is safer, but I suppose the hot wallet is a trusted entity regardless as they could sandwich regardless via a jito bundle.

We'll see how this shakes out in the implementation, but it isn't possible for non-pda signers to appear in the original message, unless we expect them to sign the inner and outer transactions.

True. I suppose we could do something where a missing inner signature can be satisfied by outer transaction signer. That sort of would be a way to designate an intended hot wallet broadcaster. Hmm, may be best to come back to this during the implementation PR. Going to drop the is_signer language here for now.

sure. more shit to maintain in the program tho. more blast radius for upstream bugs. more shit to consider during deprecation. we're patching oob panic in v1 tx parsing rn. the more the program knows, the worse off it is

the pubkey, address, account conflation in this ecosystem continues to pay out...

the account itself isn't really relevant to my point. sure it's stored at the authority's pda, but that pda is also the effective signer for inner payload execution. i don't see how it matters how many auxiliary programmatic signers we have on the inner payload, we only care about knowing which accounts index is the vault's to match the nonce stored there to what's signed on the inner payload. i'm proposing that we encode that information in the accounts list and forego duplicating the authority in the vault. so we'd have accounts indexes like this...

1. vault address
2. slothashes sysvar
3. instructions sysvar
4. vault authority pubkey
5. aux signer 1 pubkey
...
5+N. aux signer N pubkey
5+N+1. aux signer 1 pda
...
5+N+N. aux signer N pda
5+N+N+1. inner instruction account 1
...

at the cost of a (one byte?) aux signer count in the instruction payload

then the logic looks something like

// check sigs
vault = accounts[1]
vault_auth = accounts[4]
if (pda(vault_auth.address) == vault.address) {
  vault_data = VaultData::try_from(vault.data)?;
  if submit_ix_data.nonce == vault_data.nonce {
    // match aux signer[i] pda(accounts[5+i].address):accounts[5+N+i].address mappings
    // do the cpis
    ...
  }
}

i'm failing to see what storing the authority pubkey gains us

did we confirm whether or not this is in fact "deprecated"? i recall coming across deprecation attributes and deprecation allows wrt it

#1 (comment)

Think you are thinking of RecentBlockhashes.

SlotHashes is currently available.